Many enterprises use computer databases to store, organize, and analyze some of their most important information. For example, a business may employ a database to hold its sales and ordering information so that analysts can predict trends in product sales or perform other kinds of data mining for long-range planning. Because database systems are responsible for managing information vital to the organization's operation, it is important for mission-critical database systems to implement mechanisms for recovery following a database system failure.
One approach to implement disaster recovery by deploying a “standby” database system that is a replica of the business's primary database system. The standby database is typically created from a backup of the primary database, and the primary database and the standby database coordinate with each other such that the standby database keeps up with changes made on the primary database. In the event of an irrecoverable crash or other disaster, the standby database can quickly be activated (“failover”) to become the business's new primary database.
There are numerous ways to synchronize the primary database with the standby database. One possible approach is to use log files to synchronize the two databases. One common type of database log is the “redo log”, which contain records of changes that are made to the database. In many database systems, the redo log is used to reapply changes that were previously made, e.g., if it becomes necessary to restore a previously committed transaction due to occurrence of a failure. For this reason, a transaction is often not considered committed unless its redo records have been stored in some persistent way.
With standby databases, the redo log records can be sent to the standby database and applied to the data at the standby database to replicate changes that are made at the primary database. This approach takes advantage of the fact that redo logs are being created at the primary database anyway, and can therefore be cheaply leveraged to provide a replication mechanism for applying changes to the standby database.
Standby configurations can generally be classified into two broad categories, including a “high performance” category and a “no data loss” category. The high performance approach is illustrated in FIG. 1A. In this approach, a transaction is first executed at the primary database 126a, e.g., to modify a database table 132a within user data 130a. A redo log 128a includes redo records that are generated to correspond to the transaction. The redo records in the redo log 128a are transmitted from the primary database 126a to the standby database 126b. The redo records would be stored within a redo log 128b at the standby database 126b and/or applied to the equivalent database table 132b within a copy of the user data 130b to replicate the changes made at the primary database 126a. 
The hallmark of the high performance approach is that the transaction at the primary database 126a is permitted to commit without waiting for an acknowledgement that the redo records have been stored at the standby database 126b. In some configurations, the commit of the transaction at the primary may even occur prior to shipping of the redo records to the standby. Therefore, with high performance configurations, servicing a standby database imposes a negligible performance impact on the primary database since there is minimal delay and latency imposed by the requirement to maintain synchronization with the standby database. However, this configuration runs the risk of possible data loss since there is no confirmation that the redo records have actually been received at the standby database, and therefore in the event of a failure it is possible the changes made by the transaction associated with the redo records can be lost.
The no data loss approach provides greater assurance of data security as compared to the high performance approach, but at the expense of performance costs. As illustrated in FIG. 1B, the no data loss configurations protect against data loss from any single source of failure by requiring receipt of an acknowledgement from the standby database 126b before allowing the transaction at the primary database 126a to commit. When a user transaction is committed, the redo generated by that transaction must safely reside at the standby database 126b (e.g., in the redo log 128b) before the primary database 126a receives acknowledgment such that a commit can occur for the transaction. The added step of shipping the redo to the standby database and waiting for an acknowledgement imposes a delay that is included in the commit latency. Since standby databases are normally located geographically distant from the primary database (e.g., to reduce the chance of a single point of failure affecting both the primary and the standby), the network latency is typically quite significant. High performance configurations do not suffer from this possible performance degradation because user transactions do not wait for confirmation of the remote standby to be serviced before receiving acknowledgment of the commit.
Therefore, the no data loss configurations protect against data loss from any single source of failure at the expense of possibly degrading the performance of the primary database. The degree of performance degradation is directly tied to the network latency between the primary and standby databases. The greater the geographical distance between the primary and standby database, the greater the network latency between them. In contrast, the high performance configuration minimizes commit delays, but runs the risk of possible data loss since there is no confirmation that the redo records have actually been received at the standby database.
As is evident, there is a need for an improved approach that addresses at least these problems with the prior approaches.